home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Supervisor's Toolkit
/
Network Supervisor's Toolkit.iso
/
novell
/
fyidev
/
fyi_a.net
< prev
next >
Wrap
Text File
|
1996-07-10
|
61KB
|
1,818 lines
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Brequest v6.0 /l Option
DOCUMENT ID#: FYI.A.2043
DATE: 04FEB93
PRODUCT: NetWare Btrieve NLM
PRODUCT VERSION: 6.0
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
Brequest version 6.00x has a new load option, /l. This allows
another instance of Brequest to be loaded even if Brequest is
already loaded. This option is useful if the ability to run
Windows applications utilizing the Btrieve requester at the
same time running DOS VM applications using Brequest is
desired.
To run Windows applications utilizing the Btrieve requester,
Brequest must be loaded before starting Windows. To run DOS
applications in Windows, Brequest must be loaded in each DOS
session. However, if Brequest is loaded outside of Windows,
it cannot be loaded again in a DOS session. FYI.A.2022
addresses this issue by suggesting the use of WINSTART.BAT to
load Brequest before Windows. However, FYI.A.6101 points out
that Windows 3.1 will hang sporadically on exit if TSRs are
loaded with the WINSTART.BAT.
SOLUTION
Load Brequest outside of Windows for Windows applications
utilizing the Btrieve requester. In each Windows DOS session
that will be running a Btrieve application, load BREQUEST /l.
This will load another instance of Brequest that is only
available to the DOS session. This provides the DOS session
with its own copy of Brequest and prevents the DOS session
from using the instance of Brequest that was loaded before
Windows was started.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: File Level Access Using Different Versions of
Brequest
DOCUMENT ID#: FYI.A.3021
DATE: 28JAN93
PRODUCT: NetWare Btrieve NLM
PRODUCT VERSION: 6.0
SUPERSEDES: NA
SYMPTOM
NetWare allows Btrieve to write to files without appropriate
user rights.
ISSUE/PROBLEM
With Brequest v5.16, a user is able to write to a Btrieve file
if the user has Write access to the directory, even if the
user does not have Write access to the file.
SOLUTION
This problem does not exist if Brequest 6.0 is used. Brequest
6.0 uses File level access rather than Directory level access.
If a user has RWCEMFA access to a directory but only RF (read
and file scan) access to a file, Brequest 6.0 will return a
status 94 on the open call. However, Brequest 5.16 will
return status 0, and the file can be updated.
The Supervisor access to a directory works differently,
however. If the user has Supervisor access, then the file can
be opened regardless of the requester version. This is mainly
because Supervisor rights "override all Inherited Rights Masks
in subdirectories and files."
Directory Trustee File Trustee Btrieve 6.0 Btrieve
5.16
Assignment Assignment Status Status
RWCEMFA R F 94 0
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Brequest and TaskMAX
DOCUMENT ID#: FYI.A.1773
DATE: 26JAN93
PRODUCT: NetWare Btrieve NLM
PRODUCT VERSION: 6.0
SUPERSEDES: NA
SYMPTOM
Status 95; Session hung
ISSUE/PROBLEM
Can the DR DOS utility TaskMAX be used to run DOS Btrieve
applications using the NetWare Btrieve requester?
SOLUTION
Since TaskMAX is a task switching utility, and not a
multi-tasking operating system, only the current task is
active. Loading Brequest in a TaskMAX session, and then
running a Btrieve application will work, until the user
switches to another task. At this point, trying to switch
back to the Btrieve task will result in either a hung session,
or a status 95 (Session No Longer Valid) returned to the
session. This is because the SPX session between Brequest and
NetWare Btrieve on the server can not be maintained when a
session becomes inactive.
An alternative would be to load Brequest before starting
TaskMAX. However, with this configuration, only one session
can be running a Btrieve application, but this session can be
switched out for other non-Btrieve sessions, and resumed
successfully.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Determining If an Application Is Running In
Windows DOS Box
DOCUMENT ID#: FYI.A.6102
DATE: 21JAN93
PRODUCT: Btrieve for Windows
PRODUCT VERSION: 5.10a
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
How can it be determined if a DOS application is running under
Windows?
SOLUTION
An interrupt is available to determine if a DOS application is
running under Windows 3.1. The following assembly code
demonstrates the interrupt. This function call also will
determine if Windows 3.1 is running in 386 Enhanced Mode or
Standard Mode. If the function determines that Windows 3.1 is
running, it sets CX equal to 2 if Windows is running in
Standard Mode. If Windows is running in Enhanced mode, it
sets CX equal to 3.
mov ax, 160ah ;
int 2fh ; Check if in Windows 3.1
DOS box
or ax, ax ;
jz Windows31 ; Jump if Windows 3.1
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Btrieve Operation 42 (Continuous Operation)
Usage
DOCUMENT ID#: FYI.A.1774
DATE: 18JAN93
PRODUCT: NetWare Btrieve NLM
PRODUCT VERSION: 6.0
SUPERSEDES: NA
SYMPTOM
Status 20 - Btrieve not loaded; Status 1 - Invalid Operation
ISSUE/PROBLEM
The new Btrieve 6.0 operation 42, which allows Btrieve files
to be placed into Continuous Operation, and removed from
Continuous Operation, can only be called from an NLM
application. It can not be called from a workstation
application. If a workstation attempts to make a Btrieve
operation 42, a status 20 (Btrieve Not Loaded) will be
returned. Btrieve version 5.x will return a status 1 (Invalid
Operation).
SOLUTION
The Btrieve 6.0 SDK includes a sample NLM application that
demonstrates the usage of operation 42. Both the C source
code and the compiled NLM are included.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Brequest and Older Version of VIPX.386
DOCUMENT ID#: FYI.A.3022
DATE: 13JAN93
PRODUCT: NetWare Btrieve NLM
PRODUCT VERSION: 6.0
SUPERSEDES: N/A
SYMPTOM
Windows Dos Box hangs upon exit if Brequest is not unloaded.
ISSUE/PROBLEM
If Brequest is not unloaded before exiting a Windows Dos Box,
the workstation will hang. This only happens if VIPX.386
version 1.11 (19197 bytes dated 3-10-92) is used.
SOLUTION
This problem does not exist if VIPX.386 v1.13 is loaded (24362
bytes dated 09-4-92).
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Btrieve 6.0 and NetWare for SAA 1.3
DOCUMENT ID#: FYI.A.2520
DATE: 13JAN93
PRODUCT: NetWare Btrieve NLM
PRODUCT VERSION: 6.0
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
If users of NetWare for SAA want to use their file server as
a database server, they will need to get the Btrieve
requesters and utilities from NetWire or from Technical
Support, Austin.
NetWare for SAA 1.3 was bundled with the following Btrieve
components:
Brebuild.nlm 1.0b 34,347 11-16-82 4:31p
Brouter.nlm 6.0 16,767 5-11-92 1:19p
Bsetup.hlp 6.0 29,462 7-21-92 10:02a
Bsetup.nlm 6.0 32,275 7-29-92 10:44a
Bspxcom.nlm 6.0a 13,871 8-05-92 10:05a
Bspxstub.nlm 6.0 596 3-16-92 12:59p
Bstart.ncf 6.0 99 8-03-92 1:09p
Bstop.ncf 6.0 49 4-12-92 2:46p
Btrieve.nlm 6.0b 146,258 12-01-92 11:06a
Btrieve.org 6.0 145,193 5-12-92 10:08a
Btrmon.hlp 6.0 28,568 7-09-92 9:52a
Btrmon.nlm 6.0 56,856 7-16-92 2:13p
Btrun.nlm 6.0 8,742 9-09-92 1:16p
Butil.nlm 6.0 124,219 7-29-92 10:50a
Patch311.nlm (Dummy) 798 9-16-92 9:58a
Rspxstub.nlm 6.0 1,137 3-16-92 1:00p
SOLUTION
NA
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Running BREQUEST 6.0b and XQLP(O) with 2.01a
DOCUMENT ID#: FYI.A.1880
DATE: 11JAN93
PRODUCT: XQL for DOS
PRODUCT VERSION: 2.01x
SUPERSEDES: NA
SYMPTOM
"Btrieve not Loaded" error
ISSUE/PROBLEM
The following steps will cause XQLP(O) to return the message
BTRIEVE NOT LOADED when trying to load XQLP(O).
1) Load BREQUEST 6.0x
2) Load XQLP or XQLPO 2.01x
3) Unload XQLP(O).
4) Reload XQLP(O). The error message will appear at this
point.
After this, BREQUEST appears to be in memory but running a
STOP operation on Btrieve reports that Btrieve is not loaded.
However, BREQUEST will not reload.
SOLUTION
Rebooting the workstation is the only way to remove BREQUEST
from memory.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: NetWare Resources Does Not Appear Under OS/2
DOS Settings
DOCUMENT ID#: FYI.A.1952
DATE: 07JAN93
PRODUCT: Btrieve OS/2
PRODUCT VERSION: 5.10
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
To run Brequest in a DOS session under OS/2, there are a few
options, depending on whether the DOS sessions is Global or
Private. This can be configured in OS/2 2.0 (refer to
FYI.A.1870).
However, if the VSHELL.SYS device driver is not loaded, the
"NetWare Resources" option will not appear in the DOS Settings
menu. This is the option that allows the configuration of
Global or Private DOS box.
SOLUTION
Make sure that VSHELL.SYS is loaded in the CONFIG.SYS file.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Btrieve Continuous Operations and File Logging
DOCUMENT ID#: FYI.A.4203
DATE: 01OCT92
PRODUCT: NetWare Btrieve
PRODUCT VERSION: 6.0
SUPERSEDES: NA
SYMPTOM
Logging when used in conjunction with Continuous Operations
may lead to an inconsistent database.
ISSUE/PROBLEM
File logging and backups can be used to rebuild Btrieve files
in case of system failures. Continuous Operations allow
continuous access to Btrieve files while the files are being
backed up.
These two features can not be used simultaneously. While a
file is in Continuous Operation mode, the log file is still
open and being updated. If logging is activated when the file
is put into Continuous Operations mode, eventually the file
will not be in sync with the log file.
Consider the following scenario:
1. Get a backup of the Btrieve file.
2. Activate logging.
3. Touch the file (update, delete, insert).
4. Start Continuous Operations.
5. Touch the file.
6. Backup is complete; end Continuous Operations.
At this point if a power failure occurred, the backup from
step 4 would be restored. The backup would reflect all the
changes that were made in step 3. The log file, however,
would contain both the changes made in step 3 and step 5. So
if the log file is used at a later date, in conjunction with
the latest backup from step 6, some operations in the log file
are already present in the Btrieve file, and errors during the
Roll Forward process will most likely occur.
SOLUTION
Do not use logging and Continuous Operations at the same time.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Multiple Record Locks and DOS 4.01
DOCUMENT ID#: FYI.A.4204
DATE: 01OCT92
PRODUCT: Btrieve for DOS
PRODUCT VERSION: 5.10a
SUPERSEDES: NA
SYMPTOM
If more than 20 records were locked using Multiple Record
Locks, a status 81 was returned.
ISSUE/PROBLEM
An application using Btrieve for DOS v5.10a with DOS v4.01
returned status 81 when the application attempted to lock more
than 20 records with multiple locks. Raising the Btrieve /L
parameter had no effect.
The same application was running on another workstation
without problem. This workstation was running DOS v5.0. The
AUTOEXEC.BAT and CONFIG.SYS files on both PCs were identical.
SOLUTION
The user upgraded to DOS v5.0 and problem was resolved.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Router Problem under NetWare v3.11
DOCUMENT ID#: FYI.A.3228
DATE: 03FEB93
PRODUCT: Network C for NLMs
PRODUCT VERSION: 2.0e
SUPERSEDES: NA
SYMPTOM
SAPs are disappearing as they cross routers.
ISSUE/PROBLEM
When the NetWare v3.11 router code was written, it was not
expected that one would advertise multiple service names on
the same network node and socket number. When this is done,
it is possible to lose some of the SAPs as they cross routers.
SOLUTION
The easiest solution is to design the code so that each
service is supported on its own socket. An alternative way is
to advertise a common service name and then as part of the
"protocol," request a particular service.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: SQL Servers Not Visible on Local Segments
DOCUMENT ID#: FYI.A.6201
DATE: 02FEB93
PRODUCT: NetWare OS/2 SDK
PRODUCT VERSION: 2.0
SUPERSEDES: NA
SYMPTOM
If using an OS/2 SQL server over a WAN, the server may not be
seen if a query is made on a local segment.
ISSUE/PROBLEM
When a PC Client is initially started up, it will issue a
general service query broadcast for service 9A and receive
back a list of all 9A services beyond the router. If the 9A
server is on the local segment, it will not be included in the
list from the router nor will it respond to the broadcast as
expected.
SOLUTION
After the 9A server starts advertising, however, the PC Client
should be able to pick up the service. If the SQL server is
a 1.3 machine, it may not advertise regularly, if at all. In
this case, NSD004 should fix the problem. Presently, there is
no solution to the SQL server not responding to the query.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Stat() Function Does Not Return Correct Name
Space.
DOCUMENT ID#: FYI.A.4126
DATE: 01FEB93
PRODUCT: Network C for NLMs
PRODUCT VERSION: SDKd
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
The stat() function returns 0 rather than 1 for the
st_originatingNameSpace field when retrieving the status for
a Macintosh file. This occurs if the file is at the root
directory.
SOLUTION
The readdir() function returns the correct originating name
space.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Using MUX Semaphores with SPX
DOCUMENT ID#: FYI.A.6202
DATE: 29JAN93
PRODUCT: NetWare OS/2 SDK
PRODUCT VERSION: 2.0
SUPERSEDES: NA
SYMPTOM
A workstation could wait infinitely for an SPX call to
complete.
ISSUE/PROBLEM
If one issues a wait on MUX semaphores under OS/2 with one of
the semaphores in the MUX list being the ECB semaphore, the
apparent result is that the ECB semaphore will never clear.
What really happens is that the semaphore is cleared and reset
by SPX but the application is never notified of it. This
results in the wait never returning if it is set to infinite.
SOLUTION
The problem does not occur with mutex or event semaphores. If
one needs to wait on more than one semaphore, it is best to
create multiple threads that individually block one each on
each semaphore.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Using FP_SEG with Near Pointers
DOCUMENT ID#: FYI.A.6004
DATE: 29JAN93
PRODUCT: NetWare System Calls
PRODUCT VERSION: 1.0
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
The FP_SEG macro in MicroSoft's C 6.0 and 7.0 returns a
garbage segment address when passed a near pointer.
SOLUTION
Make sure that you pass far pointers only to this macro when
using MicroSoft C. Borland C++ 3.1's FP_SEG will correctly
return the current data segment of a near pointer.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Driver Load Order Using LANSUP and OS/2 v2.0
DOCUMENT ID#: FYI.A.6203
DATE: 28JAN93
PRODUCT: NetWare OS/2 SDK
PRODUCT VERSION: 2.0
SUPERSEDES:
SYMPTOM
NA
ISSUE/PROBLEM
Protocols or system loads but no NetWare support.
ISSUE/PROBLEM
When using the OS/2 driver LANSUP, the Open DataLink Interface
allowing multiple protocols on an OS/2 machine and the IBM
equivalent of ODINSUP, the order in which the drivers are
loaded is very important. A file exists in the release
version of the requester, COEXIS.TXT, that contains an example
for OS/2 1.3 and older versions of LANServer or LANManager.
This example does not work properly when using OS/2 2.0 or
LANSUP. Apparently there is also an error in the
documentation. The result is that the machine will not load
the operating system; or that it will load, but report driver
errors in the process; or that a successful initialization
will occur (no errors) but there will be no NetWare services
due to the wrong protocols being bound to the network board.
SOLUTION
The proper order involves loading the LAN Server 2.0 protocol
drivers first in the CONFIG.SYS file. Then the NetWare
Requester statements should be loaded in the following order:
device=lsl.sys run=ddaemon.exe DEVICE=LANSUP.SYS
device=ipx.sysdevice=spx.sysrun=spdaemon.exedevice=nmpipe.sy
sdevice=npserver.sysrun=npdaemon.exeetc ... where LANSUP
replaces ODINSUP.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: OS/2 Use of Extended Attributes and NetWare
DOCUMENT ID#: FYI.A.6204
DATE: 28JAN93
PRODUCT: NetWare OS/2 SDK
PRODUCT VERSION: 2.0
SUPERSEDES: NA
SYMPTOM
OS/2 File icons may disappear after the file has been moved,
copied, or restored.
ISSUE/PROBLEM
OS2 stores a file's icon information, as well as other data,
in the file's extended attributes. NetWare 2.x does not
support file extended attributes. NetWare 3.x only supports
extended attributes when High Performace File System (HPSF)
namespace is loaded. There was a feature under OS/2 1.x that
would show a program's icon for its type associated data files
that is no longer available in OS/2 2.0. Therefore, this
problem may occur when upgrading from OS/2 1.x to 2.0
regardless of the NetWare version.
SOLUTION
If Extended Attributes are required, load the HPFS namespace
NLM, OS2.NAM. Make sure that the backup software supports
long file names.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: NamedPipes Return Disconnect in Error
DOCUMENT ID#: FYI.A.6205
DATE: 28JAN93
PRODUCT: NetWare OS/2 SDK
PRODUCT VERSION: 2.0
SUPERSEDES: NA
SYMPTOM
PeekPipe or ReadPipe returns 109, Pipe Broken on a valid pipe.
ISSUE/PROBLEM
If any attempt is made to peek or read a pipe with a 0 buffer
specified, the pipe will be disconnected and error 109, pipe
broken will be returned.
SOLUTION
Specify a buffer of at least 1 byte to be used. In the case
of the peek, this will not cause a problem because the
contents are left in the pipe anyway.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: PurgeSalvagableFile Spelling Difference in
Windows
DOCUMENT ID#: FYI.A.4604
DATE: 28JAN93
PRODUCT: NetWare C for Windows
PRODUCT VERSION: 1.30
SUPERSEDES: NA
SYMPTOM
PurgeSalvagableFile shows as undefined under Windows
ISSUE/PROBLEM
The call documented as PurgeSalvagableFile in the Windows SDK
is actually spelled PurgeSalvageableFile (note the extra "e")
in the code. The other APIs document and code it like the
Windows documentation as PurgeSalvagableFile.
SOLUTION
Make sure to add the extra "e" when using the Windows version
of this call.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: GetServerInformation Always Returns 128 Bytes
in Windows
DOCUMENT ID#: FYI.A.4605
DATE: 28JAN93
PRODUCT: NetWare C for Windows
PRODUCT VERSION: 1.30
SUPERSEDES: NA
SYMPTOM
GetServerInformation may return too much data
ISSUE/PROBLEM
It does not matter what structure size you specify in
GetServerInformation under Windows. It will always return 128
bytes of data.
SOLUTION
Always allocate at least 128 bytes for the received statistics
buffer to avoid overwriting memory.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Problem Sharing Semaphores Between Multiple
Workstations
DOCUMENT ID#: FYI.A.6005
DATE: 28JAN93
PRODUCT: NetWare System Calls
PRODUCT VERSION: 1.0
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
If several workstations attempt to open the same named
semaphore using system call C5h (00h), each recognizes that
they are the only one with the semaphore open. This problem
only seems to occur when using this system call with MicroSoft
C 6.00A and MicroSoft C++ 7.0.
SOLUTION
There is no workaround at this time. Even doing the system
call with inline assembler instead of through int86() did not
solve the problem. Use one of the C APIs or switch compilers.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Diagnostics from Windows
DOCUMENT ID#: FYI.A.2674
DATE: 26JAN93
PRODUCT: NetWare C for Windows
PRODUCT VERSION: 1.3
SUPERSEDES: NA
SYMPTOM
Diagnostic API GetServerAddressTable fails with IPXODI 2.0,
and the NWIPXSPX.DLL from the 1.3 SDK.
ISSUE/PROBLEM
There are two problems that this FYI will address:
1) Using LSL/IPXODI version 2.0 causes GetServerAddressTable
to fail. Using component number 2, the workstation
crashes needing a hard reset. For component number 3, the
FindComponent is not found in the component list, thus
the function fails.
2) The NWIPXSPX.DLL that came with the SDK 1.3 has a problem
that was addressed in an earlier FYI, concerning the
NWMemmove "helper" function. It did not copy the entire
diagnostic reply to the buffers if they were larger than
255 bytes.
SOLUTION
The only known solution is to use the IPXODI v1.20 drivers.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Bug in NLM Example Program
DOCUMENT ID#: FYI.A.1529
DATE: 21JAN93
PRODUCT: Network C for NLMs
PRODUCT VERSION: All versions
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
The program on Page 3-23 of the NLM Library Reference Volume
1 is incorrect. If executed as is, the custom data for the
NLM, which is stored in the global variable (globalString),
will be NULL.
The problem is that an uninitialized global variable will be
set to NULL before the program begins execution. The data is
read into the variable, globalString, correctly; but this is
done before the uninitialized global variables have been set
to NULL.
SOLUTION
When creating the global variable, globalString, assign a
value to the string. This will prevent the string from being
set to NULL before the program executes.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: File in DOS Partition of Server Would Not
Truncate
DOCUMENT ID#: FYI.A.1328
DATE: 18JAN93
PRODUCT: Network C for NLMs
PRODUCT VERSION: 2.00D
SUPERSEDES: NA
SYMPTOM
A file in the DOS partition of a NetWare file server would not
truncate after data was modified.
ISSUE/PROBLEM
A file in the DOS partition of a NetWare file server contains
five lines. The application NLM reads the five lines and
modifies the data to only have four lines and writes it back
out. Viewing the file again indicates that the fifth line is
still in the file. The following calls were being issued:
■ DOSOpen (), DOSRead (), DOSClose ()
■ data was modified here
■ DOSOpen (), DOSWrite (), DOSClose ()
■ file was viewed here which indicated no change had
occurred
SOLUTION
The call to DOSWrite () does not cause the file to truncate if
the data length of the file to be written is less than the
original length.
The DOSWrite () writes data to a particular offset for a
particular length.
To "rewrite" a file, the second DOSOpen () listed above must
be changed to DOSCreate ().
The document states that the DOSCreate () will truncate the
file if it exists or create a file if it does not exist.
The call to DOSCreate () returns a file handle that can be
used on subsequent calls to DOSWrite () and DOSClose ().
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Bug in TTSTransactionStatus
DOCUMENT ID#: FYI.A.1530
DATE: 15JAN93
PRODUCT: Network C for NLMs
PRODUCT VERSION: SDKe
SUPERSEDES: NA
SYMPTOM
Incorrect Transaction completed status
ISSUE/PROBLEM
When using the TTSTransactionStatus() call on the local
server, CLIB is not long swapping the transaction number. An
incorrect transaction number will result one of two problems.
The TTSTransactionStatus() call may report that the
transaction has completed, erroneously; or it may never show
the transaction as completed.
SOLUTION
With CLIB v3.11d and earlier, when using the
TTSTransactionStatus() call on the local server, LongSwap()
the transaction number.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Closing Temporary Socket in BeginDiagnostics()
DOCUMENT ID#: FYI.A.4903
DATE: 15JAN93
PRODUCT: NetWare C Interface DOS
PRODUCT VERSION: 1.2
SUPERSEDES: NA
SYMPTOM
Multiple calls to BeginDiagnostics() fails after the eleventh
attempt when searching for a target.
ISSUE/PROBLEM
BeginDiagnostics() function does not close the temporary
socket.
This is an example from DIAG.C:
int GetRemoteSPXSocket( BeginDiagnosticStruct *destination,
BYTE *cList )
*
*
tempSocket = (WORD)0x4545;
if( IPXOpenSocket((BYTE *)&tempSocket, 0) )
/* after the 11th call, it now returns the 254 here */
return 1;
IPXRecvECB.socketNumber = tempSocket;
*
*
/* normally returns a 252 error here for the first 11 calls
*/
if ( IPXRecvECB.inUseFlag || IPXRecvECB.completionCode )
return IPXRecvECB.completionCode /* no response received
*/
int BeginDiagnostics(destination, connectionID, componentList
)
*
*
/* first open a socket then init receive ECBs */
tempSocket = (WORD)0x00; /* let IPX pick socket number */
ccode = IPXOpenSocket((BYTE)&tempSocket, 0);
/* call to function */
if( (ccode = GetRemoteSPXSocket(destination,componentList))
!= 0 )
Error = COULD_NOT_OPEN_SOCKET;
else
{
for (i=0; i<RESPONSE_ECBS; i++)
{
*
*
if (Error == NO_ERRORS)
{
*
*
if (ccode == 0)
{
*
*
else
Error = COULD_NOT_BEGIN_CONNECTION;
if (Error != NO_ERRORS)
IPXCloseSocket (thisECB.socketNumber);
}
else
Error = COULD_NOT_OPEN_SOCKET;
/********************************************
NOTE THAT THE TEMPORARY SOCKET IS NOT CLOSED
BEFORE THE RETURN (my comments)
********************************************/
return (Error);
SOLUTION
The fix is in the source code, DIAG.C. The function,
IPXCloseSocket(), must be called when an error occurs.
int BeginDiagnostics(destination, connectionID, componentList
)
*
*
/* first open a socket then init receive ECB's */
tempSocket = (WORD)0x00; /* let IPX pick socket number */
ccode = IPXOpenSocket((BYTE)&tempSocket, 0);
/* call to function */
if( (ccode = GetRemoteSPXSocket(destination,componentList))
!= 0 )
Error = COULD_NOT_OPEN_SOCKET;
else
{
for (i=0; i<RESPONSE_ECBS; i++)
{
*
*
if (Error == NO_ERRORS)
{
*
*
if (ccode == 0)
{
*
*
else
Error = COULD_NOT_BEGIN_CONNECTION;
/****************************************
Comment out or remove this section as it is
not necessary.
if (Error != NO_ERRORS)
IPXCloseSocket (thisECB.socketNumber);
*****************************************/
}
else
Error = COULD_NOT_OPEN_SOCKET;
/* place fix here - close temporary socket */
IPXCloseSocket (tempSocket);
return (Error);
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: OS/2 Requester Update, NSD201, Interferes with
NWTools.
DOCUMENT ID#: FYI.A.6206
DATE: 13JAN93
PRODUCT: NetWare OS/2 SDK
PRODUCT VERSION: 2.0
SUPERSEDES: NA
SYMPTOM
NWTools script files no longer work after NSD201 applied.
ISSUE/PROBLEM
NWTools script files, *.NWS, that are created with version
2.0A of the OS/2 Requester will not run properly when the
drivers have been updated with NSD201. Specific examples
include not being able to attach to a server with an NWS file.
The problem is apparently with NWTOOLS.EXE and NWTOOLS.DLL
included with NSD201. New script files may not work correctly
either.
SOLUTION
Save a backup copy of NWTOOLS.EXE and NWTOOLS.DLL before
installing NSD201.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Interrupt Line 21, Function 3F Bug in Shell
DOCUMENT ID#: FYI.A.6006
DATE: 13JAN93
PRODUCT: NetWare Shell
PRODUCT VERSION: 3.31
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
If a section of a file is locked with Interrupt line 21
function 5C00 and another workstation using the file tries to
read from the locked area the call appears to succeed, even
though it should fail. The carry flag is supposed to be set
and an error code returned in the AX register. The error code
(5 in this case) is being returned but the carry flag is not
being set so the contents of the AX register are processed as
the number of bytes read instead of as an error code. There
is no way to tell if an error has occurred in this case. This
bug has been found in NETX.EXE v3.26 and v3.31 but may exist
in others.
SOLUTION
NA
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: How to Attach to Multiple File Servers with
the Same Password
DOCUMENT ID#: FYI.A.2947
DATE: 12JAN93
PRODUCT: NetWare C for Windows
PRODUCT VERSION: 1.3
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
If a user has the same password across multiple file servers,
how can a developer write an application that does not prompt
this user for their password every time they attach to a
different file server?
If a user is logged in to one server and needs to attach to
another file server, the user's login script can be modified
to contain add the attach command to the other file servers.
However, the user will have to synchronize passwords across
multiple file servers to avoid having to enter a password
every time attaching to a new file server.
This is not the case on the DOS command line, regardless of
the fact that the user's passwords are synchronized or not on
multiple servers. If the user is logged in to one server and
wants to attach to another server, the password will have to
be reentered.
The reason is that the attach login script command has a
different set of code than the attach command on the DOS
command line. The attach login script command will not prompt
the user for a password if the password is synchronized
because it is built into the login routine. However, the
attach command on the DOS command line will always prompt for
a password.
SOLUTION
There is no way to attach to multiple servers without entering
the password. However, Novell has a set of code that can be
purchased just like any other product. This code will enable
an application to attach/login to multiple servers without
having the user enter each password.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: min() and max() Are Both Macros and Functions
DOCUMENT ID#: FYI.A.6007
DATE: 08JAN93
PRODUCT: Network C for NLMs
PRODUCT VERSION: 2.0d
SUPERSEDES: NA
SYMPTOM
Compiler errors in STDLIB.H
ISSUE/PROBLEM
min() and max() are defined as macros in STREAM.H but are
prototyped as functions in STDLIB.H. If STREAM.H is included
before STDLIB.H, the compiler attempts to expand the prototype
in STDLIB.H with the macro from STREAM.H. This results in
syntax errors in STDLIB.H.
SOLUTION
Always include STREAM.H after STDLIB.H, or go into the
STDLIB.H file and replace the prototypes with copies of the
macro definitions from STREAM.H.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: VerifyNetworkSerialNumber() Causes Lost
Connection
DOCUMENT ID#: FYI.A.1329
DATE: 08JAN93
PRODUCT: NetWare System Calls
PRODUCT VERSION: 1.2
SUPERSEDES: NA
SYMPTOM
A call to VerifyNetworkSerialNumber() with an invalid serial
number will cause the calling workstation to lose its network
connection.
ISSUE/PROBLEM
If the networkSerialNumber parameter does not match the
network's serial number, the calling workstation will lose its
connection to the network. The documentation does not state
this; however, this is the way the function is supposed to
work. The return values are only valid if the match occurs
and some other error causes a nonzero return code.
SOLUTION
NA
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Home Directory Flag
DOCUMENT ID#: FYI.A.3861
DATE: 06JAN93
PRODUCT: NetWare C Interface DOS
PRODUCT VERSION: 1.2
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
Where is the flag stored for creating the home directory for
a newly created user?
SOLUTION
This flag, which is 1 byte, is stored at offset 64 in the
USER_DEFAULTS property of the SUPERVISOR. If it is nonzero,
SYSCON will prompt for the creation of the home directory if
a new user is created.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Status 517 with XQL and Forest and Trees
DOCUMENT ID#: FYI.A.2120
DATE: 31JAN93
PRODUCT: XQL
PRODUCT VERSION: 2.11
SUPERSEDES: NA
SYMPTOM
Status 517 returned on SELECT statement
ISSUE/PROBLEM
When accessing Platinum DDFs using Forest and Trees for
Windows, if XQL v2.11 is loaded, a SELECT * FROM <TableName>
statement will return a status 517 - "The From Clause is
Missing" when obviously a FROM clause is present.
SOLUTION
Platinum DDFs delimit their table names with semicolons that
causes XQL to interpret the table name; as the end of the SQL
statement, thus, producing a status 517. Newer DDFs that do
not have these semicolon delimiters are available from
Platinum.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Outer Join on a Computed Field
DOCUMENT ID#: FYI.A.1775
DATE: 29JAN93
PRODUCT: NetWare SQL
PRODUCT VERSION: 3.0
SUPERSEDES: NA
SYMPTOM
Status 875; Status 220
ISSUE/PROBLEM
When a CREATE VIEW statement is used to create a view with a
computed field whose resulting type is an integer, that
computed field is considered to be a 4-byte integer. This is
important when using this field as part of an outer (or null)
join because the data type and length of the join fields must
match exactly for an outer join. For example, in the
following statement, the field T2 is a 4-byte integer
containing the value 100:
CREATE VIEW Test (T1, T2) AS SELECT F1, 100 FROM
Tbl1
Consequently, the following statement will only work if
TBL2.FLD is a 4-byte integer and is also an index (or first
segment of an index) on table Tbl2:
SELECT * FROM Test, Tbl2 WHERE Test.T2 =
Tbl2.fld(+)
If either of these conditions is not met, a status 220 "No
Matching Index on Secondary Keys" will be returned.
Currently, there is a problem with NetWare SQL v3.0b where the
above SELECT statement will return an error 875 "Only a right
Outer Join Is Supported," even if TBL2.FLD is a 4-byte integer
and an index.
SOLUTION
If the view is created at the Relational Primitive level
instead of using SQL statements, the xCompute function is used
to specify the computed field. The xCompute function has
parameters that allow the application to specify both the type
and size of the resulting field. In this case, the computed
field can be created as a 2- or 4-byte integer, whichever is
needed for the outer join.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Blank User in USER.DDF Causes Security
Problems in Xtrieve
DOCUMENT ID#: FYI.A.1130
DATE: 27JAN93
PRODUCT: Xtrieve PLUS
PRODUCT VERSION: 4.1x
SUPERSEDES: NA
SYMPTOM
Status 205 when loading Xtrieve PLUS
ISSUE/PROBLEM
Years ago, it was possible to set up a blank user when
installing security on data dictionary files. Currently,
blank users are not supported. If a blank user exists in
USER.DDF, then Xtrieve cannot be loaded without returning a
status 205, which indicates "Invalid Password."
The reason this error occurs is with the way Xtrieve logs into
a set of DDF files. Xtrieve first attempts an xLogin to the
dictionaries. If a status 209 (Invalid User) is returned,
Xtrieve attempts to do another xLogin prompting for the user
name and password. However, if anything other than a status
209 is returned to Xtrieve on the first xLogin call, then
Xtrieve will not prompt the user for the user name and
password.
When Xtrieve attempts its first xLogin call, it always passes
a blank user name and a blank password. Normally, this would
return status 209 on a dictionary with security installed.
However, because there is a blank entry in the USER.DDF file,
a status 205 is returned instead. Because Xtrieve does not
trap for anything but a status 209 on the xLogin, the status
205 would be relayed to the user of Xtrieve.
It is interesting to note that XQLI will prompt for a username
and password if security is installed on the data dictionary
files, without attempting an initial XQLLogin call. XQLI will
prompt the user for a password even if the user name is blank.
So, the status 205 will not occur when logging in through XQLI
unless the password specified is invalid.
SOLUTION
To work around the problem, remove the blank user from
USER.DDF. BSIM.EXE, B.EXE, or any utility that provides
Btrieve or XQLP function calls will do the trick.
The DDF files have Btrieve owner names on them when security
is installed. The Btrieve owner name on the DDF files will be
the same as the master password specified when security was
installed. The USER.DDF file can be checked for a blank user
first, by running BUTIL -SAVE down key path 0. If there is a
blank user, then using a Btrieve or XQL utility, read the
record with the blank user then delete it from the Btrieve
file.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Update Problem with NetWare SQL
DOCUMENT ID#: FYI.A.1776
DATE: 26JAN93
PRODUCT: NetWare SQL
PRODUCT VERSION: 3.0b
SUPERSEDES: NA
SYMPTOM
Only one record updated
ISSUE/PROBLEM
If an UPDATE SQL statement is sent to NetWare SQL that has a
restriction based on a field that is an index, only the first
record matching the restriction will be updated.
Example:
UPDATE Appointments SET Amount^Due = 0.00 WHERE
ID > 0
This command will only update the first record having ID
> 0 if ID is an index in the Appointments table. All
other records will remain as they were.
This problem was introduced by the December patches for
NetWare SQL v3.0.
SOLUTION
Use NetWare SQL with the September patch release installed.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: Running Out of NetWare SQL Connections
DOCUMENT ID#: FYI.A.2948
DATE: 25JAN93
PRODUCT: NetWare SQL
PRODUCT VERSION: 3.0
SUPERSEDES: NA
SYMPTOM
Status 266 on a xLogin or XQLLogin call
ISSUE/PROBLEM
The NetWare SQL documentation states the Error Message 266
"Number of Sessions Logged in Exceeds Maximum." However, it
does not provide any explanation on the real reason for this
message.
The documentation should state that if a five-user copy of
NetWare SQL is installed and all five connections are in use,
a sixth user will not be able to log into a database. The
NetWare SQL Monitor Utility (NDBMON.NLM) can be used to see
which users currently have connections to NetWare SQL.
SOLUTION
Use only what is allowed in terms of SQL connections on your
SQL server.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: VIEW.DDF and Owner Names
DOCUMENT ID#: FYI.A.1131
DATE: 22JAN93
PRODUCT: Xtrieve Plus
PRODUCT VERSION: 4.1x
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
When security is installed on a set of data dictionary files,
each .DDF file is assigned a Btrieve owner name that is the
same as the Master password with one exception: the VIEW.DDF
file does not have a Btrieve owner name assigned. Why is this
the case?
SOLUTION
Because multiple VIEW.DDF files can reference one or more set
of DDFs, these files do not "belong" to any particular set of
DDFs and cannot be assigned an owner name specific to one set
of DDFs. Therefore, there is never an owner name assigned to
a VIEW.DDF file.
There is only one exception to having multiple VIEW.DDF files
that reference one set of DDFs; see FYI.A.1120 for this
information pertaining to named database support under NetWare
SQL 3.0.
FYI
(Note: The origin of this information may be internal or external
to Novell. Novell makes every effort within its means to verify
this information. However, the information provided in this
document is FOR YOUR INFORMATION only. Novell makes no explicit or
implied claims to the validity of this information.)
TITLE: More on XQL and .SHR Files
DOCUMENT ID#: FYI.A.1777
DATE: 12JAN93
PRODUCT: XQL for DOS
PRODUCT VERSION: 2.11
SUPERSEDES: NA
SYMPTOM
NA
ISSUE/PROBLEM
In a previous FYI (FYI.A.1759, XQL and .SHR Files), a
description of how XQL creates and maintains a .SHR file was
explained. Another anomaly has been found regarding this
issue. If XQL is patched so that it can be accessed from
within Windows and then loaded from the WINSTART.BAT file, the
.SHR file is created in the users current directory when
Windows was started. Subsequently, if the user opens a DOS
session and from the same directory, tries to load XQL again,
one of two things will happen:
1. If DOS SHARE was loaded before Windows, a Sharing
Violation Error will be returned and XQL will not load
2. If DOS SHARE was not loaded, XQL will overwrite the .SHR
file already present with a new .SHR file. Subsequently,
unloading XQL from this DOS session will cause this .SHR
file to be deleted. This means that the XQL that was
loaded by WINSTART.BAT no longer has an available .SHR
file to use. This will eventually lead to status 202 or
821 (Invalid Cursor ID) errors to be returned.
The previous situations occur only when the .SHR files are
being created on a local drive. If the current working
directory is a NetWare drive, this problem does not exist; two
.SHR files are properly created and maintained in the same
NetWare directory.
SOLUTION
If using a local drive, load XQL inside the DOS session from
a different directory than the current working directory when
Windows was started or specify an /x: parameter on the XQL
load line pointing to a different directory. See the previous
FYI.A.1759 for more information about the /x: parameter.